In a wireless network, a wireless terminal may be capable of providing other terminals with network access. For example, an integrated user equipment (UE)—e.g. a cell phone—typically obtains connectivity to a particular packet data network (PDN) via a wireless interface, such as WLAN, GPRS or LTE; and the UE also allows other terminal equipments (TEs) to attach to the UE using local connectivity technologies—e.g., IrDA, USB, and Bluetooth—and the UE grants the TEs access to the PDN. In this case, the UE and attached TEs forms a network, and may move around as a whole.
Host Based Mobility Protocols
In a host-based mobility protocol, e.g., DSMIPv6, a UE (or mobile node (MN)) typically extends its Internet Protocol (IP) stack and implements IP mobility signaling as the UE moves and changes its point of attachment. For this reason, DSMIPv6 is often referred as a client-based mobility protocol (CMIP).
FIG. 1 illustrates a conventional attach procedure 100 during which a UE 102 gains network connectivity to a home network via a foreign link (or visited network). At step 110, UE 102 performs a layer 2 specific attach procedure with an access router (AR) 104. At step 112, UE 102 performs a layer 3 specific procedure to configure an IP address on an interface of UE 102. At step 114, UE 102 initiates a bootstrapping procedure to obtain an IP address of a HA 106, if not available, using either DHCP or DNS. At step 116, UE 102 runs an IKEv2 protocol with HA 106 to establish an IPSec security association.
During step 116, UE 102 also requests a home address (HoA) or a home network prefix (HNP), and UE 102 compares the received HoA or HNP with the IP address previously configured on the interface of the UE at step 112. If they do not match, the IP address previously configured on the interface is a care-of address (CoA), and UE 102 performs steps 118, 120. In particular, at step 118, UE 102 registers the binding between the care-of address and the home address in a Binding Update message with HA 106. Upon receiving this Binding Update message, HA 106 creates a binding between the care-of address and the home address in a Binding Cache entry. At step 120, a Binding Acknowledgement message, if requested, is sent back from HA 106 to notify UE 102 of the status of the Binding Update procedure. Note that the binding update message and the binding acknowledgement message are protected by the IPSec security association established at step 116.
If at step 116 the received HoA or HNP does match the IP address previously configured on the interface of UE 102, UE 102 is at its home link and steps 118, 120 are not performed. Note that optionally UE 102 may set up an additional child SA to protect payload traffic from the UE itself. At step 414, user equipment 306 gains network connectivity and can send or receive data traffic from a correspondent node (CN) 312 at the current point of attachment via either the home address or care-of address based, e.g., on the DSMIPv6 specification.
When a UE powers up as a mobile router, in addition to the information listed above, the UE also needs to obtain a mobile network prefix from the PDN that the UE wants to access. Once obtained, the mobile network prefix is advertised or announced to the attached TEs in order for the TEs to configure an IP address for accessing such PDN. Note that the home address obtained by the mobile router may or may not be within the range of the mobile network prefix. It is possible to pre-configure the UE with a mobile network prefix; however, this results in inefficient use of a network prefixes—i.e., the network prefix would be locked to a specific UE even when the UE is powered off. Currently, there are two mechanisms that can be used for a UE to dynamically obtain such a network prefix—DHCP based prefix delegation, and MIP signaling based prefix delegation.
FIG. 2 shows a procedure 200 for a UE 202 to run DHCP to obtain a mobile network prefix from an HA 204. At step 210, UE 202 performs a layer 2 specific attach procedure with an access router (AR) 204. At step 212, UE 202 performs a layer 3 specific attach procedure to configure an IP address on an interface of UE 202. At step 214, UE 202 starts a bootstrapping procedure to obtain an IP address of HA 206, if not available, using either DHCP or DNS. At step 216, UE 202 runs an IKEv2 protocol with HA 206 to establish an IPSec security association. During this step, UE 202 also requests a home address (HoA) or a home network prefix (HNP). UE 202 compares the received HoA or HNP with the IP address previously configured on its interface.
If the received HoA or HNP does not match the IP address, the IP address configured on the interface of UE 202 at step 216 is a care-of address (CoA) and UE 202 performs steps 218, 220 as shown in box (A). That is, at step 218, UE 202 registers a binding between the care-of address and home address in a Binding Update message with HA 206. Upon receiving this Binding Update (BU) message, HA 206 creates a Binding Cache entry based on the care-of address and the home address in a Binding Cache. At step 220, a Binding Acknowledgement (BA) message, if requested, is sent back from HA 206 to notify UE 202 the status of the Binding Update procedure. (Note that BU and BA messages are protected by the IPSec security association established at step 216).
If the received HoA or HNP does match the IP address, UE 202 is at its home link and steps 218, 220 are skipped. Note that optionally UE 202 may set up an additional child SA (security association) to protect payload traffic from UE 202. At this point, UE 202 gains network connectivity and can send or receive data traffic (from a correspondent node (CN) 208) at its current point of attachment via either the home address or care-of address based on, e.g., the DSMIPv6 specification.
When UE 202 uses a DHCP based prefix delegation mechanism, UE 202 acts as a DHCPv6 requesting router (RR) and HA 206 acts as a DHCPv6 delegating router (DR) or a DHCPv6 relay agent (if other entity in the home network acts as a DHCPv6 delegating router). The information about the delegated mobile network prefix is exchanged between UE 202 and HA 206 by using an IA_PD Prefix option in the DHCPv6 message. If UE 202 does not have any active delegated prefix(es), UE 202 initiates a DHCPv6 message exchange by sending a DHCPv6 Solicit message to HA 206 (step 222), and HA 206 returns a DHCPv6 Reply message to UE 202 (step 224) (as defined in section 17 of RFC 3315 and section 12 of RFC 3633). And if UE 202 has one or more active delegated prefixes, UE 202 initiates a DHCPv6 message exchange with a DHCPv6 Confirm message as described in section 18.1.2 of RFC 3315 and section 12 of RFC 3633.
If UE 202 is at its home link, DHCP messages for prefix delegation can be exchanged between UE 202 and HA 206 directly and HA 206 must update its routing table, e.g. by specifying the next hop to the delegated prefix to be the home address of the UE 202. If UE 202 is not at its home link, DHCP messages for prefix delegation are exchanged through a tunnel between UE 202 and HA 206 and steps 226, 228 shown in box (B) must be performed. If the explicit mode is used, UE 202 registers the binding between its care-of address and home address as well as the delegated mobile network prefix in a Binding Update message with its HA 206 (step 226), as specified in Network Mobility (NEMO) Basic Support Protocol, RFC 3963. If the explicit mode is used, upon receiving this Binding Update message, HA 206 creates a Binding Cache entry based on the care-of address, the home address and the delegated home network prefix in the Binding Cache. A Binding Acknowledgement message, if requested, is sent back from HA 206 (step 228) to notify the Mobile Node the status of the Binding Update procedure.
Note that if implicit mode is used for the UE to register the binding, the HA must have to update the corresponding Binding Cache entry with the delegated mobile network prefix; however this requires an additional API/interface between DHCP protocol and MIP protocol. DHCPv6 Prefix Delegation for NEMO recommends using explicit mode. Now the attached TE can configure its IP address from the delegated mobile network prefix and obtain IP connectivity to access the PDN through the UE. Note that optionally the UE may set up an additional Child SA to protect payload traffic from/to the delegated mobile network prefix.
With the MIP signaling based prefix delegation mechanism, the Binding Update message is extended for the UE to indicate its request of a mobile network prefix and the Binding Acknowledgement message is extended for the HA to return the delegated prefix to the UE. Therefore, this mechanism is only useful when the UE attaches to a foreign link because when the UE attaches to its home link, there is no any BU/BA message exchange. FIG. 3 shows a procedure 300 for a UE 302 to run MIP signaling to obtain a mobile network prefix from an HA 306.
At step 310, the UE performs the layer 2 specific attach procedure with a local access router (AR) 304. At step 312, the UE then performs a layer 3 specific procedure to configure an IP address on its interface. At step 314, the UE then starts a bootstrapping procedure to obtain the IP address of the home agent, if not available, using either DHCP or DNS. At step 316, the UE runs an IKEv2 protocol with the home agent to establish the IPSec security association. During this step, the UE also requests a home address (HoA) or a home network prefix (HNP). Then the UE compares the received HoA or HNP with the IP address previously configured on its interface during step 312. If they do not match, the IP address configured on the UE's interface at step 2) is a care-of address; otherwise, the UE is at its home link and the IP address configured on the UE's interface at step 2) is a home address. In this case, we assume that the UE is not at its home link in order to demonstrate the procedure of MIP signaling based prefix delegation. Note that optionally the UE may set up an additional Child SA to protect payload traffic from the UE itself.
Tat step 318, the UE registers a binding between its care-of address and home address and also requests a mobile network prefix by including a Mobile Network Prefix request option in a Binding Update message with its home agent. Upon receiving this Binding Update message, the HA verifies the request of the UE and assigns a mobile network prefix, if the request is valid. The HA creates a Binding Cache entry based on the care-of address, the home address and the delegated mobile network prefix in the Binding Cache. A Binding Acknowledgement message must be sent back from the HA to notify the Mobile Node the status of the Binding Update procedure and the delegated mobile network prefix (carried in the MNP option) (step 320). Note that BU and BA messages are protected by the IPSec security association established at step 316. Now, the UE gains network connectivity and it can send or receive data traffic (from a correspondent node (CN) 308) at its current point of attachment via its care-of address based on the DSMIPv6 specification. Furthermore, the attached TE can configure its IP address from the delegated mobile network prefix and obtain IP connectivity to access the PDN through the UE. Note that optionally the UE may set up an additional Child SA to protect payload traffic from/to the delegated mobile network prefix.
Prefix Delegation Support for Mobile Networks describes another prefix delegation mechanism that combines both DHCP based and MIP signaling based prefix delegation mechanisms, which mechanism is illustrated by procedure 400 in FIG. 4. With this mechanism, the UE does not act as a requesting router, but requests a MNP using an extended Binding Update message (step 408); and the HA acts as a requesting router and requests prefix delegation using DHCP messages from a DHCP server (i.e., a delegating router) (steps 410, 412, 414, 416), and returns the delegated prefix back to the UE in the Binding Acknowledgement message (step 418).
Network Based Mobility Protocols
A UE can also establish connectivity to a certain PDN by using network based mobility protocols, such as GTP and PMIP.
FIG. 5 shows a procedure 500 in which a UE 502 establishes network connectivity by using PMIP. Different from the procedure of using host based mobility protocols, PMIP does not require the UE to be involved in mobility signaling; instead, an entity called Media Access Gateway (MAG) (e.g., MAG 504) acquires the home network prefix (either from the policy profile or from the home agent (also called Local Mobility Anchor (LMA))) (LMA 506), and then emulates the UE's home link. The UE configures its home address from the home network prefix acquired by the MAG (step 510). The MAG also acts as a proxy agent to setup connectivity for UE with the LMA by sending a Proxy Binding Update message (step 512), and receiving the Proxy Binding Acknowledgement message (step 514). Upon the completion of this procedure, a mapping between the Care of address of MAG and the home address of UE is created at the LMA, which enables the LMA to forward the packets destined at the UE to the appropriate MAG (via tunnel 516). With the DHCP based prefix delegation mechanism, the UE, after receiving the home address/home network prefix from the MAG, sends a DHCPv6 message to request a mobile network prefix. The MAG acts as a DHCPv6 relay and forwards such message to the LMA that acts as a DHCP server, and returns an allocated mobile network prefix to the UE via the MAG.
FIG. 6 shows a procedure 600 of how connectivity is established through GTP. The detailed procedure is described in 3GPP TS 23.401. By default, when the UE requests an IPv6 home address, the UE performs a stateless IPv6 address configuration after initial attach by sending a Router Solicitation message to the PDN GW and receiving a Router Advertisement message from the PDN GW. After address configuration, the UE can request prefix delegation by acting as a DHCPv6 client and exchanges DHCPv6 messages with the PDN GW that acts as a DHCP server.
As described above in connection with host based mobility protocols, a UE can use DHCP based and MIP signaling based prefix delegation mechanisms to obtain a mobile network prefix. Such mechanisms may be suitable in the case that the TE does not attach to the UE to access network initially when the UE powers up, but attaches later. However, it is quite common that there are TEs waiting for network access before the UE activates its wireless interface to obtain network connectivity. In this case, it is important for the UE to obtain a mobile network prefix as soon as possible in order to reduce the delay for TE's waiting time.
When the UE is at its home link, the UE cannot use MIP signaling based prefix delegation mechanism; on the other hand, when the UE is not at its home link and the UE uses DHCP based prefix delegation mechanism, either additional BU/BA message exchange is needed or an additional API/interface between the DHCP protocol and the MIP protocol needs to be implemented. Furthermore, if the user traffic between TEs and the HA needs to be protected by IPSec and the security association established before is only for the traffic from/to the UE itself, but not for the traffic to/from the allocated mobile network prefix, either an additional IPSec Child SA is needed or the traffic from/to the mobile network prefix is encapsulated by the IP header firstly and then processed by the previously established security association, which results in significant overhead. Third, with both mechanisms, the UE cannot obtain its home address and one or more mobile network prefixes at the same time. Therefore, typically the HA does not know whether the UE needs a mobile network prefix or not when the UE establishes the IPSec SA with the HA and the mobile network prefix returned to the UE later will likely not include the home address (e.g., a /64 IPv6 HNP) assigned to the UE before. is because otherwise the HA will have to avoid allocating any address/prefix from the corresponding shorter (e.g., a /48 IPv6 prefix) prefix to other UEs, which results in insufficient use of network resources. There are certain benefits if the home address falls into the range of the allocated MNP, for example, the UE only needs one IPSec Child SA to protect the traffic from/to the UE and the TEs. Prefix delegation mechanisms should not exclude such kind of configuration.
Besides these two mechanisms, the following existing approaches might be relevant to this topic. MIP6 Bootstrapping in Split Scenario (RFC 5026) defines an attribute, called MIP6_HOME_PREFIX, to be used in IKEv2 Configuration Payload messages to carry the home network prefix from which the Mobile Node auto-configures its home address. However, this attribute cannot be used for requesting and returning the mobile network prefix; otherwise it would cause confusion.
Internet Key Exchange (IKEv2) Protocol (RFC 4306), and IKEv2 Clarifications and Implementation Guidelines, (RFC 4718) defines another attribute—called INTERNAL_IP6_SUBNET. Such attribute can be used in IKEv2 CFG_REPLY payload to indicate a network prefix. However, using this attribute for mobile network prefix delegation has the following drawbacks. First, such attribute intends to indicate what prefix is accessible through an IPSec gateway (without link boundary), and together with the Traffic Selector payload (such as TSr), whether an IPSec SA is needed to access this prefix and if so, whether the IPSec SA to be created or a new IPSec SA should be used for this purpose, based on the operator's policy; therefore, this attribute cannot be used for mobile network prefix delegation. Second, there is no clear meaning when using this attribute in the CFG_REQUEST message; RFC 4718 recommends not including this attribute in the CFG_REQUEST payload.
For the similar reasons, the attributes of INTERNAL_IP4_NETMASK and INTERNAL_IP6_NETMASK cannot be used for this purpose either. Furthermore, there are no corresponding payloads for prefix delegation in network based mobility signaling messages and stateless IP address configuration messages.